- 


Vy" 


This report is a selective reprint of material contained in Communications Systems. A two- 
volume loose-leaf.information service covering integrated communications systems. For 


additional information on this product and others contact Data Decisions, Inc, 20 Brace 
Road, Cherry Hill, NJ 08034. Telephone 800-257-7732; in NJ (609) 429-7100. 


INTERCOMM 


SDA Products, Inc. 


Products @ SDA Products INTERCOMM @ page 1 


SDA Products INTERCOMM 
TP Monitor System 


@ PROFILE 


Function e multithread TP monitor for IBM systems 


Computers/Operating Systems Supported e IBM System/370 
(Model 135 .and up), 3000, 4300, and compatible comuters; 
OS/VS1, OS/VS2 (SVS and MVS), VM/370 


Networks & Protocols e SNA; SDLC and all standard IBM 
protocols 


Language Interfaces e COBOL, FORTRAN, PL/1, and IBM 
Assembler 


DBMS Interfaces e available for IMS (DL/1), Cincom TOTAL, 
Software AG ADABAS, Cullinane IDMS, CCA Model 204, and 
Intel System 2000/80 


TP & File Access Methods e BTAM, TCAM, VTAM: BDAM, 
BSAM, QSAM, BISAM, QISAM, and all other standard IBM 
access methods except BPAM 


Terminals e most standard IBM asynchronous, synchronous, and 
SDLC devices plus all compatible devices 


Special Features e optional Front-End interface; Generalized 
Front-End Interface (GFE) Special Feature; Generalized DBMS 
Interface (GDB); Multiregion Support Facility (MRS); CICS 
Compatibility Feature (unsupported); AUTOGEN feature; 
Dynamic File Allocation (DFA) Special Feature 


Security e station, transaction, or station/transaction 
sign-on/sign-off security plus user-defined file access control via 
system-supplied command/control subsystem 


Logging/Accounting e internal system log (INTERLOG); System 
Accounting and Measurement (SAM) charge-back accounting 
facility available 


Failure Recovery e user-defined and system-controlled data 
checkpoint definition; recovery analysis uses log entries and 
accounting routines; system quiesces to checkpoint; thread 
continues when log is repositioned to failure point 


Current Version e 8.0 


Installations e 250 


Comparable Systems e TS! International TASK/MASTEBR; 
Cincom ENVIRON/1 


Vendor e SDA Products, Inc; 475 Park Avenue South, New York, 
NY 10016 e 212-481-6800 


@ ANALYSIS 
INTERCOMM is one of the oldest IBM-compatible communi- 


cations monitors in the marketplace. It was introduced in 1968 by 
Programming Methods Inc (PMI) and was later acquired by 


PURCHASE PRICE RANGE Software License Purchase ES 
Software Service Fees as | 


license purchase 
@ S69K 

5-yr service fee 

0$28K 


5-yr total cost (sum of above) 
$69K to $97K 


$40K $80K $120K $160K $200K 


SDA PRODUCTS INTERCOMM PRICING @ solid bar shows single license 
purchase price, which includes all package facilities; open bar shows 5-year 
service fee but is calculated for 4 years (48 mos) because first-year maintenance 
is included in license purchase price. 
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Informatics. Its sister TP monitor package, MINICOMM, also 
became part of Informatic’s repertoire of proprietary software. In 
1979, both INTERCOMM and MINICOMM were sold to SDA 
Products, Inc, a subsidiary of Software Design Associates. 


INTERCOMM is a highly technical, multifunctional telecommuni- 
cations monitor with many table-driven, preprogrammed 
functions that minimize the amount of coding required from the 
applications programmer. For large OS/VS-class computer 
installations, only a few competitive systems can match the 
flexibility and richness of options available with INTERCOMM. 


O Strengths 


INTERCOMM has a large repertoire of preprogrammed, 
automatically initiated facilities. It incorporates almost every 
communications operation one would expect of a sophisticated 
teleprocessing monitor. Users comment positively on its 
multithreading operations, its multiregion support capabilities, its 
ability to release program resources when no longer needed, and 
many other multiuser-support features. INTERCOMM has an 
exceptionally comprehensive recovery mechanism that supports 


recovery and restart under the most catastrophic failure 


conditions. INTERCOMM is unquestionably one of the best TP 
monitors on the market. 


@ OVERVIEW 
Oo ‘Terms & Support 


Terms e INTERCOMM is available on a purchase basis only; all. 
operational facilities are included in the single, bundled price 
agreement; the license covers an entire facility, which may 
encompass multiple CPUs; multiple-copy discounts of 25% apply 
to additional licenses within the same company. 


Support e maintenance, installation support, and training for the 
first year are included in the cost of the license; maintenance for 
successive years costs approximately 10% of the then-current 
license fee; installation support can run from 3 days to 10 days if 
necessary; concepts and facilities and application development 
courses are conducted on-site after installation is completed; 
complete documentation is also included in the sale, and hot-line 
support is available for problem resolution. 


O Component Summary 


INTERCOMM's facilities are configured by the user from a menu 
of selectable features provided by the vendor. The features are all 
included (bundled) under one system price to the purchaser. 
Significant selectable features are summarized as follows: 


Message Mapping Utilities (MMU) e transforms terminal- 
dependent formats to terminal-independent form and vice versa; 
initiated by a call from the application program. 


AUTOGEN Facitity e generates MMU macros online from sample 
screens input from an IBM 3270 (or compatible) CRT. 


Data Entry System e provides a preprogrammed general-purpose 
data entry/verification capability. 


Dynamic File Allocation (DFA) e permits an application to 
dynamically create and retrieve sequential data sets. 


Generalized Front-End Facility (GFE) e provides the basic 
structure for interfacing to nonstandard communications devices. 


Dynamic Data Queuing Facility (DDQ) e allows applications to 


dynamically create, retrieve, and delete logical data sets and/or. 


queues of messages on a single BDAM data set. 


Page Facility e allows terminal operators to browse through a 
multiscreen output message. 
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Model System Generator (MSG) e provides a working system 
based on user specifications to model the eventual system. 


Multiregion Support Facility (MRS) e allows groups of application 


subsystems to execute in separate regions while the 
INTERCOMM Front-End resides in a Control Region. 


CICS Compatibility Feature (CF) e an unsupported SDA product 
that allows application programs written for execution under 
standard IBM CICS/OS to execute under INTERCOMM control; 
no IBM-supplied CICS modules are reguired. 


O Product Definition 


INTERCOMM is a large-scale telecommunications monitor 
designed to support an IBM OS/VS environment. It competes 
directly with IBM's CICS/OS program product. INTERCOMM 
consists of four distinct facilities: subsystem control, file handling, 
dispatching, and a teleprocessing interface. Communications are 
provided for device and line control operations; full resource 
management, job management, and task/program management 
capabilities. are available, as are a host of utility program and 
options to tailor the system to special environments. 


INTERCOMM e totally bundled system including all user- 


selected features: 
$69,375 lens 


@ FUNCTIONAL FACILITIES 


NA mo $6,900 serv 


O Computers/Operating Systems 


INTERCOMM can be installed on any IBM System/370, 3000, 
4300, or compatible computer capable of running under 
OS/VS1, OS/VS2(SVS), or OS/VS2(MVS). Operations are also 
supported under VM/370. 


O Minimum Operating Requirements 


The basic INTERCOMM system requires a minimum of 100K 
bytes of main storage. An additional SOK bytes (minimum) of main 
storage are required to support dynamic queue, control block, 
buffer, table, and I/O areas. SDA reports that INTERCOMM is 


currently supporting a system with over 2,500 terminals. 
O Protocols & Network Interfaces 


All standard IBM protocols and access methods (excluding 
BPAM) are supported, including SDLC. INTERCOMM also 
supports the networking facilities of SNA and can handle a wide 
variety of non-IBM asynchronous and synchronous terminals. 


O Access Methods 


The full range of IBM-supported access methods is supported 
under INTERCOMM. These include BTAM, TCAM, and VTAM for 
support of SDLC/SNA devices. INTERCOMM also provides the 
GFE (Generalized Front-End) hardware line control computer 
interface for connecting several front-end minicomputer systems. 


O File/DBMS Interface 


Although INTERCOMM can be configured to interface with 
general-purpose, homegrown data structures, it is used primarily 
with one of several popular database management systems. 
Standard interfaces are provided for Cincom TOTAL, IBM IMS 
(DL/1), Software AG ADABAS, Cullinane IDMS, Computer 
Corporation of America Model 204, and Intel System 2000/80. 


SDA Products can provide nonstandard interfaces on special; 


order. 
O Temporary Storage & Paging Facilities 


INTERCOMM is table oriented and supports both dynamic and 
fixed storage buffering. The system's Resource Manager facility 
can allocate and assign core resources independently’ of the 
standard operating system GETMAIN/FREEMAIN facilities. The 
TP monitor is basically a multithread system but can be degraded 
to a single thread environment if necessary. All core and disk 
queues are managed automatically by the system, and the 
number of threads supported depends solely on the amount of 
including security functions, checkpoint/restart specifications, 
and logging requirements; and utility control, including MMU 


resources available to the system. Thread lengths are not fixed 
because each portion of an application program is handled as a 
separate program segment. Each message is processed as 
completely as possible until the application subsystem voluntarily 
gives up control. An optional Store/Fetch facility can temporarily 
store data in main memory or on disk. It is identified by a 
user-assigned key of up to 48 characters. This capability is 
sometimes referred to as a “scratch pad’ facility. 


The paging constraints of INTERCOMM are governed directly by 
the paging characteristics of the operating system. The Virtual 
Execution Group storage scheduling technique utilizes the 
operating system paging algorithm to manage program 
residency. It strives to optimize page loading to achieve the 
highest level of page utilization with the least number of page 
faults. The Look-Ahead-Page-Load facility checks each critical 
page boundary movement to ensure that needed pages are 
resident in real memory. Thus, when a potential page fault is 
detected, the system can pre-load the necessary page(s) 
overlapped with processing for other message traffic. 


INTERCOMM supports three page fixing methods: the user can 
provide a list of system or user modules to be fixed at system 
initialization time; the INTERCOMM control terminal operator, 
through the use of terminal commands, can dynamically fix or 
unfix individual modules in main storage; or the INTERCOMM 
Time-Zone utility can be used with the VS system control to alter 
page-fix characteristics during selected time periods. 


O Message Switching Facilities 


The Subsystem Controller and Dispatcher routines handle. all 
message switching functions. The path of each message is 
controlled by one or both of these routines. Control includes 
acquiring the message from the queue, formatting it, obtaining 
required data from online files, executing the application 
program, formatting the response, and directing the output to the 
proper terminal. Message switching is supported between 
application programs, terminals, and/or system programs either 
through a direct interface to the INTERCOMM queuing routine 
(via a two-parameter CALL) or by an INTERCOMM-supplied 
subsystem. Through a series of priority structures, a message can 
be analyzed and sent on to a lower priority subsystem for 
processing. . 


If a receiving terminal is unable to receive a message, 
INTERCOMM reroutes the message to an alternate device, if one 
was specified, or queues the message until the receiving terminal 
comes up again, at which time all accumulated messages for that 
terminal are transmitted. All operating system task management 
and message transfer control are bypassed by INTERCOMM, and 
the operating system regains control only when no messages or 
when all messages are awaiting completion of I/O operations. 
Messages on queues waiting for transmission are preserved 
across system failures by a Message Restart facility. The 
highly-parameterized Message Mapping Utilities (MMU) 
subsystem provides an interface between the application 
subsystem and any terminal-dependent message processing 
logic for both input and output messages. All tasks within queues 
are dispatched on a first-in/first-out basis within priority levels. 


@ USER INTERFACES 
O Languages Supported 


INTERCOM\M interfaces with application programs written in 
COBOL, FORTRAN, PL/1, and IBM assembler language. 


O Host Operating System Interface 


INTERCOMM interfaces with the host operating system through 
macro-generated tables. Tables exist for such system functions as: 
line contro}, including network configuration and transaction 
identification; message processing control; system control, 


LCNS: purchase price includes I year of service, installation 
support, and 2 weeks of on-site training. NA: no lease terms 
are offered. SERV: annual maintenance and enhancement 
charges after the first year. Prices effective as of September 
1981. 


Filing Sequence 980-5462 OU06Y 02 © page 2 


©1982 Data Decisions 


Communications Systems @ February 1982 


Products @ SDA Products INTERCOMM @ page 3 


SDA Products INTERCOMM 
TP Monitor System 


requirements, edit utility requirements, output utility formatting 
specifications, and display/change utility file descriptions. Other 
system-oriented tables are: a Verb Table, which lists all the valid 
transaction codes required for processing; Station Table and 
Device Table, which describe terminal device-dependent 
characteristics; System Parameter Table, which describes 
system-wide operating characteristics; a Data.Set Control Table, 
which is generated automatically by the File Handler function:to 
describe online data sets; and the Subsystem Control Table, 
which lists the characteristics (reentrancy, language, entry point, 
etc), queue specifications (core and/or disk queues), and 
scheduling specifications (resident or loadable, concurrent 
message processing limits, etc) for each subsystem: 


In addition, INTERCOMM provides the user with station, 
transaction, and station/transaction sign-on/sign-off security. A 
full range of operator commands is available, and INTERCOMM 
allows user programs to place application log entries on the 
system log data set to clarify the status of message processing in 
the case of system failure. 


QO Batch Processing 


Although INTERCOMM is designed to operate primarily in an 
online mode, batch operations can be handled easily through 
basically the same facilities used in the online environment. If 
both an online application and a batch task need to update a file 
concurrently, the File Handler is placed in the operating system's 
Link Pack Area so that the batch program can perform its I/O 
against the files via calls to the File Handler. This procedure 
avoids update problems and maintains file integrity. 


O Transaction Processing 


All transaction processing is handled by the INTERCOMM * 


Teleprocessing Interface, which controls the communications 
processing between the host computer and the connected 
terminals. User programs do not interface directly with terminals; 
they utilize a queuing mechanism that operates independently of 
the operating environment. All Interface operations are 
transparent to the application program and include all message 
polling, addressing, and transmission functions. The File Handler 
performs all of the file accessing for the application programs. The 
File Handler notifies the Dispatcher of all 1/O activities to provide 
internal task overlap management. The File Handler also controls 
files in a way that precludes updating conflicts. Multiple programs 
can access files in parallel. 


The Subsystem Controller searches the control table for the next 
program/task. Once it receives a message from the process 
queue, it activates the appropriate program to start message 
processing. The Edit routine is one of the real-time utilities 
available with INTERCOMM. It is used to prepare messages from 
the terminals for processing by the applications programs. The 
Edit utility strips off the control characters and superimposes a 
predefined format onto the message. An Output utility determines 
the format of the output message/data, obtains the data to make 
up the output, and produces the actual message for the 
designated terminal. After the communications control characters 
are appended to the message, the message is passed back to the 
Telecommunications Interface for actual transmission. 


O Program Development 


In the INTERCOMM environment, an application program is a 
subsystem that executes under the control of the Subsystem 
Controller. Many of the programming services offered by this 
subsystem are invoked automatically. These include a monitor 
service via a standard call, conversation processing with a 
terminal, support for both nonreusable and/or nonreentrant 
- programs, single-thread operations if required, a variety of 
mapping utilities, automatic conversational facility, multiscreen 
CRT output browsing, facility for subtasking applications with 
embedded WAITs, and automatic release of program resources in 
a failure situation. Application programs can be written in 
COBOL (ANS or IBM F), PL/1 (IBM F or Optimized), FORTRAN G 
or H, or the IBM assembler language. The application logic 
analyzes the input message, but the file is actually accessed by 
either INTERCOMM or a DBMS interface service routine. The 
application program can create one or more response messages 
to be sent to the originating terminal and/or other terminals. 


O Security 


INTERCOMM offers an extensive set of security facilities. The 
standard system-supplied options include sign-on/sign-off 
security at the station, transaction, or station/transaction level. 
The user can also specify what operator is allowed to enter what 
type of transaction from which terminal. A system-supplied set of 
Extended Security System facilities supports more 
comprehensive control to system resources in a multiregion or 
single region INTERCOMM system and allows the security 
environment to be defined dynamically via a command language 
available to the user. Finally, many user exits are supplied to 
implement custom security routines and procedures. 


O Monitoring & Evaluation 


INTERCOMM maintains the INTERLOG system log, which 
contains a historical record of all traffic within the monitor. It 
provides for system control and maintains complete performance 
documentation. It is a variable-length sequential data set that can 
reside optionally on disk or tape. System log entries are 
automatically posted at key processing points. Each message is 
logged at the time of entry on a subsystem queue. Aside from 
INTERCOMM system log entries on INTERLOG, the user can 


gather information from various user log entries. These entries 


can be instrumental in gathering statistics about specific ° 


operating conditions. In addition, application programs can place 
information on the system log data set. A charge-back accounting 
facility called SAM (System Accounting and Measurement) 
interacts with information gathered in INTERLOG. Some of the 
statistics gathered for performance analysis include: terminal 
status, which can be requested at any time for any duration of 
time: file statistics, for assessing file organization and I/O 
frequency; subsystem statistics, which show the number of 
messages processed by each subsystem; off-line statistics, which 
can be generated per terminal, per transaction, or per application 
program, and which can be used to produce traffic histograms 
and/or response time reports; storage utilization statistics, which 


-constitute global and/or detail core-use information; and system 
‘tuning statistics, which is an optional facility that allows 


INTERCOMM to gather information relating to its own 


performance characteristics. In all cases, the user specifies the * 


testing period for gathering the statistics. 
O Failure Recovery Methods 


The checkpoint/restart capability available with INTERCOMM is 
based on the system log. Checkpoint data is written to the log at 
checkpoint time. At restart time, the data is restored exactly as it 
was when the last checkpoint was taken. An option permits user 
data to be included in the checkpoint. The Message Restart 


facility restarts messages from the point of system failure and . 


restores the status of all messages that had completed input 
transmission. Recovery consists of reading the log in reverse 
sequence and replacing uncompleted messages into the 
application program or into terminal queues. Message 
classification and selectivity priorities can be established during 
restart. Both the restart and normal modes of INTERCOMM 
operate concurrently within a single execution. New messages 
are accepted from a live terminal network as soon as the log is 
repositioned to the failure point. The restart facility is transparent 
to the user, but the user is responsible for the table entries made at 
the system level. The entire restart system is coordinated with the 
recovery of the operating system files and/or DBMS file data. 
Data recovery is aided through the use of the File Recovery 
Special Feature, which is used to restore online disk files in the 
event of system failure. INTERCOMM also employs before-image 
and after-image processing to restore records. 


A Backout-on-the-Fly (BOF) restart facility is executed following a 
program check, a program time-out, or a special request by a 
subsystem. BOF follows the same methodology as file recovery 
and requires the Dynamic Data Queuing (DDQ) Special Feature. 
BOF places the thread's before and after images on a DDQ. If the 


thread completes successfully, then the DDQ is deleted. If the 


thread fails, it is backed out, and standard recovery action is 
invoked. 


e END 
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